It would be interesting to do some bench-marking vs a native lua implementation

@IamPete1 Here's one I put together:

-- Show various CRC calculations

--CRC16 Xmodem
local inString = "Hello, world! This is a test string. 50 bytes long"

--CRC16 via pure Lua
local function crc_xmodem_update(crc, data)
    crc = crc ~ (data << 8)
    for i = 0, 7 do
        if (crc & 0x8000) ~= 0 then
            crc = (crc << 1) ~ 0x1021
        else
            crc = crc << 1
        end
    end
    return crc & 0xFFFF
end

local function crc_xmodem_lua(data)
    local crc = 0
    for i = 1, #data do
        crc = crc_xmodem_update(crc, string.byte(data, i))
    end
    return crc
end

local function update()
    local start = micros()
    -- so 3 crc and take the average time
    for i = 1, 3 do
        crc = crc_xmodem(inString)
    end
    local stop = micros()
    local delta = (stop - start)/3

    gcs:send_text(3, "CRC16 (bindings) is: " .. string.format("0x%04X", crc))
    gcs:send_text(3, "CRC16 (bindings) calculated in " .. tostring(delta) .. " us")

    start = micros()
    for i = 1, 3 do
        crc = crc_xmodem_lua(inString)
    end
    stop = micros()
    delta = (stop - start)/3

    gcs:send_text(3, "CRC16 (pure Lua) is: " .. string.format("0x%04X", crc))
    gcs:send_text(3, "CRC16 (pure Lua) calculated in " .. tostring(delta) .. " us")

end

-- wrapper around update()
function protected_wrapper()
    local success, err = pcall(update)
    if not success then
        gcs:send_text(MAV_SEVERITY.ERROR, "CRC: Internal Error: " .. err)
        -- when we fault we run the update function again after 1s, slowing it
        -- down a bit so we don't flood the console with errors
        return protected_wrapper, 5000
    end
    return protected_wrapper, 5000
end

-- start running update loop
return protected_wrapper()

Calculating the CRC16 of a 50 byte string has the following execution time on a CubeOrangePlus:

• 15-20usec using the Lua bindings
• 900-1400usec using the pure Lua implementation.

So the Lua bindings are ~50x faster

Those timings are remarkable.

@stephendade not a good idea to mix in the streamrate changes with the 9704 support. Please split that out to a separate PR for separate discussion (I think I'm OK with it, but I'm wondering if we should add an option bit to allow people to use initial stream rates if they are still keen to do so).

Calculating the CRC16 of a 50 byte string has the following execution time on a CubeOrangePlus:

• 15-20usec using the Lua bindings
• 900-1400usec using the pure Lua implementation.

So the Lua bindings are ~50x faster

Ouch. I guess the binding is worth it.

My only hesitation is that I don't want to have a binding for every crc. How would you feel about a more generic binding where you can pass the polynomial?

My only hesitation is that I don't want to have a binding for every crc. How would you feel about a more generic binding where you can pass the polynomial?

If that ends up as the solution please put the common polynomials (ex. MAVLink, CRSF) in docs.lua as a comment.

@stephendade not a good idea to mix in the streamrate changes with the 9704 support. Please split that out to a separate PR for separate discussion (I think I'm OK with it, but I'm wondering if we should add an option bit to allow people to use initial stream rates if they are still keen to do so).

Done. See #31331.

My only hesitation is that I don't want to have a binding for every crc. How would you feel about a more generic binding where you can pass the polynomial?

My own thoughts are we only add bindings for commonly used CRC's. Looking through the AP_Scripting, the Xmodem CRC is used in >5 scripts, so that seems an obvious candidate.

Somewhat related: #27355 . There is a reasonably well defined taxonomy of CRCs more than the polynomial that we do not exploit.

You could also make the Lua faster by using a table, at least likely to the point doing it in Lua is not a performance concern. Several other Lua scripts already do this.

This also makes me more concerned about doing mavlink CRC checks in the script in #31268 . I will do some investigation myself.